Secure remote control

ABSTRACT

Remote control of equipment located on an organisation&#39;s intranet can be achieved by using proxy and client secure access controllers which communicate using a peripheral control protocol (PCP) over a predefined port number. By allowing only outbound connections over the firewall protecting the intranet and using SSL/TLS authentication and encryption, a high level of security is maintained. A similar arrangement at a control station is used to permit monitoring of equipment at a remote site without allowing inbound connections over the firewall which protects the remote station.

The present invention relates to the field of remote control of devicesover a network, particularly but not exclusively to the remote controlof conferencing equipment based at a customer's premises.

With the general trend towards networking various equipment locatedwithin and across an organisation's sites, the potential for remotelymanaging such equipment is increasing. Such remote management can bedone from a central location within the organisation or, in many cases,from a location external to the organisation. For example, in the caseof conferencing equipment used for audio and video conferencing and thelike, there is a need for external remote control of the equipment toset up conferencing facilities on demand.

The equipment installed at the organisation's premises, for example,multipoint control units (MCUs), may be of mixed manufacturer origin andtherefore use different and usually proprietary control protocols,although these are commonly transported over an IP (Internet Protocol)network layer usually including the TCP (Transport Control Protocol)transport layer protocol.

By convention, the control protocol in use is indicated by a TCP fieldcalled the port number. Problems arise when implementing control ofdiverse pieces of equipment over networks that include firewalls, as thefirewall has to be opened for every different combination of port numberand IP address required by the various control protocols. The opening ofmultiple holes in the firewall is usually resisted by firewall managers,as it increases management complexity and greatly reduces security.

In addition, many pieces of equipment are controlled using SimpleNetwork Management Protocol (SNMP), which it is inadvisable to allowthrough firewalls, as much network equipment is itself managed usingthis protocol.

One configuration which addresses the above problem is shown in FIG. 1,illustrating the control of equipment 1, 2 at a remote site 3. Theequipment 1, 2 is controlled over an insecure wide area network 4 from acontrolling site 5. The equipment 1, 2 is located on a local areanetwork 6 in a ‘demilitarised zone’ DMZ between an outer firewall 7facing the insecure network 4 and an inner firewall 8 protecting acorporate intranet 9. A device referred to herein as a secure accesscontroller 10, is located on the local area network in thede-militarised zone DMZ. The secure access controller 10 is anapplication program running on a conventional computer, which acts as aserver and implements communications conforming to a single protocol,referred to herein as peripheral control protocol (PCP). It interfacesto the individual pieces of equipment 1, 2 via equipment drivers.

The equipment 1, 2 in the DMZ can then be remotely controlled by aclient at the controlling site 5 connecting to the secure accesscontroller 10. The equipment at the controlling site 5 comprises acontrol station 11 protected from the insecure network 4 by inner andouter firewalls 12, 13. The control station 11 connects to the secureaccess controller 10, using PCP over port 1073, which has beenregistered for this purpose with IANA, the Internet Assigned NumbersAuthority. Therefore the secure access controller 10 requires port 1073in the outer firewall 7 to be open for incoming connections. This portalso has to be open for outbound connections on the inner and outerfirewalls 12, 13 at the controlling site 5.

In the event that equipment is connected to the corporate intranet 9,access to the corporate intranet 9 through the inner firewall 8 isrequired. Port 1073 would therefore need to be opened on the innerfirewall 8. Since the inner firewall 8 is the final line of defence forthe corporate intranet 9, the opening of this connection inevitablyposes an additional security risk.

The present invention aims to address the above problems.

According to one aspect of the invention, there is provided a system forremotely controlling one or more devices over a communications network,wherein the network includes first and second network sides and meansfor controlling access between the first and second sides, the systemcomprising a first controller connected to the network on the firstnetwork side for receiving device control messages from a controlstation and a second controller connected to the network on the secondnetwork side, for receiving the device control messages from the firstcontroller and controlling the one or more devices in response thereto,wherein the first controller is configured to send the device controlmessages to the second controller after initiation of a connection tothe first controller by the second controller.

The access control means, for example a firewall, can be configured toprevent connection requests from the first controller from reaching thesecond controller.

By only allowing a communications path to be set up between the firstand second controllers at the instigation of the second controller, noinbound connections are made to the second network side, for example acorporate intranet. The only connections which are permitted through thefirewall are outbound connections, so significantly enhancing security.

By keeping the connection open once it is made, device control messagescan be forwarded to the second controller whenever they are received atthe first controller, without requiring the first controller to requesta connection to the second controller, which would be an impermissibleinbound connection.

According to the first aspect of the invention, there is also provided amethod of remotely controlling one or more devices over a communicationsnetwork, wherein the network includes first and second network sides andmeans for controlling access between the first and second sides, themethod comprising initiating a connection to a first controllerconnected to the network on the first network side from a secondcontroller connected to the network on the second network side andsending device control messages from a control station to the firstcontroller and then from the first controller to the second controller.

According to a second aspect of the invention, there is provided asystem for remotely monitoring one or more devices over a communicationsnetwork, wherein the network includes first and second network sides andmeans for controlling access between the first and second sides, thesystem comprising a monitor station connected to the network on thefirst network side for receiving information concerning said one or moredevices, a first controller connected to the network on the secondnetwork side for receiving said information and sending said informationto the monitor station and a second controller for monitoring the one ormore devices and sending said information to the first controller,wherein the first controller is configured to send said information tothe monitor station after initiation of a connection to the firstcontroller by the monitor station.

By only allowing a communications path to be set up between the monitorstation and the first controller at the instigation of the monitorstation, no inbound connections are made to the controlling site. Theonly connections which are permitted through the access control means,for example, a firewall, are outbound connections, so significantlyenhancing security. Similarly, event notifications are made on anoutbound connection from the second controller to the first controller,so no inbound connections need to be made through the firewallseparating the first controller from the second controller. Eventsoccurring at a remote site can therefore be securely monitored.

In response to the monitored events, device control messages can begenerated and sent to control the devices.

According to the second aspect of the invention, there is also provideda method of remotely monitoring one or more devices over acommunications network, wherein the network includes first and secondnetwork sides and means for controlling access between the first andsecond sides, the method comprising initiating a connection to a firstcontroller connected to the network on the second network side from amonitor station connected to the network on the first network side andsending event information relating to the one or more devices from thesecond controller to the first controller and then from the firstcontroller to the monitor station.

Embodiments of the invention will now be described, by way of example,with reference to the accompanying drawings, in which:

FIG. 1, which has already been described above, illustrates a networkconfiguration which permits remote control of equipment at a remote siteusing a secure access controller;

FIG. 2 illustrates a network configuration according to one aspect ofthe invention, in which a client controller communicates with a proxycontroller to enable remote control of equipment at a remote site;

FIG. 3 illustrates the set-up of a connection between the client andproxy controllers;

FIG. 4 is a schematic diagram illustrating a remote control system forsetting up conference;

FIG. 5 is a flowchart illustrating the operation of the system of FIG.4;

FIG. 6 illustrates a network configuration according to a second aspectof the invention, in which a client controller communicates with amonitor station via a proxy controller to permit the monitoring ofunsolicited events, such as alarms, at a remote site;

FIG. 7 illustrates the set-up of a connection between the monitorstation and the proxy controller;

FIG. 8 is a flowchart illustrating the operation of the system of FIG.6;

FIG. 9 illustrates a network configuration according to a third aspectof the invention, in which a client controller communicates with a proxycontroller and the proxy controller in turn communicates with a centralcontroller to enable remote control of equipment at a remote site; and

FIG. 10 illustrates the set-up of a connection between the proxy andcentral controllers.

FIG. 2 is in certain basic aspects of network arrangement similar toFIG. 1 and the same reference numerals are used to identify commonaspects. As in FIG. 1, the equipment to be controlled 1, 2 is located ata remote site 3 and is remotely controllable over a network 4 from acontrolling site 5. However, in contrast to the arrangement shown inFIG. 1, the equipment 1, 2 is connected to the corporate intranet 9 atthe remote site 3, rather than being located in the DMZ. A secure accesscontroller 20, referred to herein as a client controller, is alsoconnected to the corporate intranet 9. A second secure access controller21, referred to herein as a proxy controller, is located in thedemilitarised zone DMZ between an outer firewall 7 facing the network 4and an inner firewall 8 facing the corporate intranet 9. The clientcontroller 20 interfaces to the individual pieces of equipment 1, 2 viaequipment drivers, and both the client and proxy controllers 20, 21operate according to peripheral control protocol (PCP), using PCP overport 1073. PCP is a generic protocol which enables communication withany type of equipment. The structure and functionality of the secureaccess controllers 20, 21 will be described in more detail below.

The inner firewall 8 does not permit inbound connections to the clientcontroller 20 on port 1073. It is configured to permit outboundconnections on port 1073 only. Therefore, the security of the corporatenetwork 9 is maintained.

Each of the client and proxy controllers 20, 21 comprises an applicationprogram running on a conventional networked personal computer (PC). Thecomputer runs under, for example, the Windows NT™ operating system andas well as the secure access controller software, has all the othernecessary hardware and software to enable it to perform its function.The entire network arrangement operates in accordance with the TCP/IPset of protocols, although PCP is transportable over a variety ofprotocols, including TCP/IP, HTTP, T.120 and SNMP.

Each of the control station 11, the proxy controller 20 and the clientcontroller 21 are issued with certificates for the purposes ofauthentication. As, generally, there is a closed group of authorisedclients, the certificates are authorised locally by an internalcertification authority, providing for a very secure system.

The operation of the remote control system and the functionality of eachcontroller 20, 21 within it is now described in detail below.

Referring to FIG. 3, on startup, for example when the client controller20 is first booted up, the client controller 20 sends a TCP (TransportControl Protocol) connection request to the proxy controller 21 on port1073 (step s1). On the assumption that the proxy controller 21 isalready online, it acts as a server listening for incoming connectionrequests. When it receives the connection request, it returns a responseto the client controller 20 (step s2), which in turn sends anacknowledgment to the proxy controller 21 (step s3), resulting in theestablishment of a TCP connection between the two, in a way which isstandard and well known. Subsequently, mutual authentication andencryption set-up is carried out between the client and proxycontrollers 20, 21 (step s4) using the industry standard Secure SocketsLayer (SSL) protocol, or the latest version known as the Transport LayerSecurity (TLS) protocol, in a way which is, once again, very well known.Once a properly authenticated connection between the client controller20 and the proxy controller 21 is established as a result of thisprocedure, the connection remains open, subject to equipment failure,scheduled maintenance and so on, ready for the transfer of instructionsfrom the proxy controller 21. The client controller 20 will continuallytry and re-establish the connection if it is lost. It may have to dropand re-establish the connection on a scheduled basis if the innerfirewall 8 only allows continuous connections to exist for a certainmaximum time.

Referring to FIGS. 4 and 5, when a user 22 requires a conference, forexample a video conference, to be arranged, he or she contacts aconference control system 23 at the controlling site 5 (step s10). Theconference control system 23 includes, for example, a plurality oftelephone operators 24, and an automated booking system 25 contactableover the Internet 26. The operators and automated booking system areconnected to a conference resource manager CRM 27. The user provides therequired details of the requested conference, for example the requiredtime, selected participants 28, 29, 30 and so on and these are suppliedto the CRM 27 by the booking system 25 or by an operator 24 (step s11).The CRM 27 determines whether all the necessary resources are availableat the time for a given conference booking request, accepts or rejectsbookings on that basis, stores the booking in a database 31 and respondsto the operator accordingly (step s12). The booking includes aconference identification number allocated to the conference to uniquelyidentify it, together with all the necessary control informationrequired to set up the equipment for the conference. The CRM 27 refersto pre-allocated identification numbers to identify the equipment to becontrolled and is allocated its own identification number on connectionto the proxy controller 21. The equipment to be controlled is, in thisexample, a multipoint control unit (MCU) 2 for controllingvideoconferencing. A control/interface module 32 then polls the database31 to extract the relevant information (step s13) and establishes aconnection with the proxy controller 21 in a conventional way over port1073, using the TCP and SSL/TLS protocols, as described above inrelation to the connection between the client and proxy controllers 20,21 (step s14).

The control/interface module 32 uses the PCP protocol, which will bedescribed in more detail below, to communicate the control informationrequired to set up the conference to the proxy controller 21 (step s15).

The PCP protocol is based on strings of 8-bit ASCII text charactersdefining a set of simple commands, such as ‘Define Conference’, ‘ExtendConference’ and so on.

For example, to set up a conference, the following message is sent,which comprises a series of commands concatenated into a single string.Each command comprises a string of 8-bit ASCII characters separated bycolons and enclosed in square brackets.

For example, a simple 2B H.320 audio/video dial-out conferencedefinition may be as follows:

[RT:D2:S1][CD:I1234:Cconf1:H1:B1:L60:N3:U3]

[RT:D2:S1][PD:I1234:Pparticipant1:J1:B2:D0:C1:N621455:M633600:C2:N621456:M633601]

[RT:D2:S1][PD:I1234:Pparticipant2:J1:B2:D0:C1:N612285:M633602:C2:N621286:M633603]

[RT:D2:S1][PD:I1234:Pparticipant3:J1:B2:D0:C1:N620479:M633604:C2:N620470:M633605]

The first command in the message comprises a command code which is atwo-letter pair followed by parameters. The code ‘RT’ is a routingcommand, which defines the source and destination for the message. Thisis followed by a parameter ‘D’, the function of which is to identify thedestination, and a parameter ‘S’ which functions to identify the source,each in combination with a value which is unique for each site. So inthis case, the Routing command RT specifies that the message is intendedfor the piece of equipment whose ID number is 2 (:D2) at the site beingaddressed and the source CRM has a client ID of 1 (:S1).

The second command includes a ‘Define Conference’ command code (CD),which defines the conference specific parameters. The conference IDnumber (:I1234) is defined by the CRM 27 to uniquely identify theconference. Other parameters shown set in the message above are theconference name (:Cconf1), the fact that it is H.320 (:H1), uses two Bchannels (:B1), is 60 minutes long (:L60) and has three participants(:N3), of which all three have definitions to follow (:U3). Any othernecessary conference parameters are also set in this command, or in anoptions command following it. Defaults can be provided for anyparameters which are not explicitly set. Some of the parameters, forexample B, are enumerated types, so the number shown is a type ratherthan an actual value.

As no time parameter (:T) is specified in the conference definition,then it is assumed to be required straight away. Conferences with a timein the future can be booked if the remote site has a local bookingfacility, for example, a local CRM. The message is addressed to thelocal CRM, which is treated in the same way as any other equipment bythe secure access controller.

A conference is not fully defined until all the participants have beenspecifically defined using the ‘Participant Definition’ command (PD).

The Participant Definition commands PD supply the participant names(:P), their bitrate (:J), the fact that they dial out (:D) and gives thecustomer number (:N) and MCU port number (:M) for each channel (:C). Thenumber of channels defined is given by (:B), in this case (:B2)specifies two channels.

Referring again to FIG. 5, on receipt of the message at the proxycontroller 21 (step s16), the proxy controller 21 forwards the messageover the previously established communications path to the clientcontroller 20 (step s17). At the client controller 20, the message isrouted to the relevant driver for the equipment identified by ID numberD2 (step s18). The equipment driver is a Windows .dll file which isspecific to the equipment being controlled, in an exactly analogous wayto printer and other hardware drivers. The driver converts the PCPmessage into the equipment specific protocol (step s19) and sends it tothe equipment to effect the required control (step s20). For example,the MCU 2 then begins the conference by connecting the participants 26,27, 28. In the event that the manufacturer provides the equipment 1, 2with a server type interface for control purposes, this can be used bythe driver to control the equipment.

Most conference commands have a response. For example, if the aboveconference starts successfully, a possible response is:

[RT:D1:S2][CS:I1234:L7777:S2:T2000.03.01.12.30][PS:I1234:Pparticipant1:S2]

[RT:D1:S2][PS:I1234:Pparticipant2:S2][PS:I1234:Pparticipant3:S2]

The Conference State (CS) command indicates that the conference has beenstarted (:S2) at the stated time and the Participant State (PS) commandsindicate that the participants have all been added and have joined theconference (:S2). The above commands also indicate that the conferencehas been allocated a local ID by the MCU (:L7777).

The responses are returned to the conference control system 23 toindicate progress of the conference and the connection between thecontrol/interface module 32 and the proxy controller 21 can then beclosed. Further unscheduled responses can be returned, for example, whena participant leaves a conference early or when the conference endsearly; these require the control/interface module 32 to hold itsconnection with the proxy controller 21 open. An alternativearchitecture for the monitoring of unsolicited responses will bedescribed below with reference to FIG. 6.

The conference control system 23 therefore achieves remote control ofthe equipment 1, 2 in a relatively secure manner. Although this is doneover a connection through the internal firewall 8 into the corporateintranet 9, the connection is initiated by the client controller 20 andcannot be initiated by the proxy controller 21, since the necessary port1073 on the inner firewall 8 is not configured to be open for inboundconnections.

While a limited number of the available PCP protocol commands andoptions have been set out above, the protocol can include a large numberof commands and options to implement the required equipment control. Itwill be understood that other protocol commands and options can beprovided by modifying the secure access controller software to generateand process these commands. For example, options can be provided underthe CD command to specify a conference password or video resolution andvideo frame rate for a video conference. Commands can be added to extenda conference currently in progress or add participants, to terminateparticipants, to extract billing information from the MCU 2 and toperform a variety of maintenance tasks for determining correct operationand correcting errors. Commands can also be introduced for controllingequipment other than conferencing equipment.

In a further embodiment illustrated in FIG. 6, the network arrangementat a remote site 3 is the same as that shown in FIG. 1, with theequipment 1, 2 to be controlled being located on a local area network 6in a ‘demilitarised zone’ DMZ between an outer firewall 7 facing aninsecure network 4 and an inner firewall 8 protecting a corporateintranet 9.

A secure access controller 30 for controlling the equipment 1, 2 is alsoconnected to the local area network 6. However, the secure accesscontroller 30 is not directly controlled by a control station, but actsas a client controller to a proxy controller 31 located in the DMZbetween the inner and outer firewalls 12, 13 at thecontrolling/monitoring site. In this embodiment, the control stationcomprises a control/monitoring station 32.

Referring to FIG. 7, the set-up of a connection between thecontrol/monitoring station 32 and the proxy controller 31 is entirelyparallel to the set-up of the connection between the client and proxycontrollers 20, 21, as shown in FIGS. 2 and 3. Therefore, thecontrol/monitoring station 32 initiates the connection over port 1073(step s21), the proxy controller responds (step s22), thecontrol/monitoring station acknowledges (step s23) and SSL/TLSnegotiation (step s24) results in an authenticated connection beingestablished. The proxy controller 32 is prevented from initiating aconnection to the control/monitoring station 32 by the inner firewall 12at the controlling site 5. Once established, the connection between thecontrol/monitoring station 32 and the proxy controller 31 remains open,in an analogous way to the connection between the client and proxycontrollers 20, 21 described in relation to FIG. 2 above.

Referring to FIG. 8, on the occurrence of an event at the remote site,for example an alarm on an item of equipment being triggered (step s25),the client controller 30 detects the event (step s26) and opens a secureconnection to the proxy controller 31 using PCP over port 1073 asdescribed above (step s27). The event information is sent to the proxycontroller (step s28), which in turn relays it back to thecontrol/monitoring station 32 (step s29) over the previously establishedconnection. The control/monitoring station 32 then sends the appropriatecontrol information back to the proxy controller 31 (step s30), whichforwards it to the client controller 30 (step s31). As in the case ofthe previous embodiment, the message is passed to the appropriateequipment driver (step s32), which converts the PCP message into thedevice specific commands required to control the equipment 1, 2 (steps33) and sends the commands to the equipment where they are used toachieve the necessary control (step s34). The connection between theclient and proxy controllers 30, 31 is then closed (step s35). It opensagain in response to further unsolicited events at the remote site.

In this example of the invention, inbound connections are prevented frombeing made to both the control/monitoring station 32 and the remote site3, so providing a relatively secure control and monitoring system.

Although the remote site 3 in this embodiment has been described ashaving the architecture of FIG. 1, where the client controller 30 andequipment 1, 2 is located in the DMZ, it could alternatively have thearchitecture of FIG. 2, where the client controller 30 and equipment 1,2 are connected to the corporate intranet 9.

In a third embodiment illustrated in FIG. 9, the network arrangement ata remote site 3 is the same as that shown in the embodiment of FIG. 2,the same reference numerals being used to identify the same features. Asin FIG. 2, the equipment to be controlled 1, 2 is located at a remotesite 3 and is remotely controllable over a network 4 from a controllingsite 5. However, in contrast to the embodiment described above withreference to FIG. 2, the outer firewall 7 of the remote site 3 does notpermit inbound connections to the proxy controller 21 on port 1073. Itis configured to permit outbound connections on port 1073 only. Thus, inapplying the same principles as applied to preserve security of thecorporate network 9 in the embodiment of FIG. 2 above, the security ofthe proxy controller 21 is similarly maintained. There is a furtheradvantage that the configuration of the outer firewall 7 at each remotesite 3 is simplified in that it does not need to be opened up toconnection requests from one or more control stations 11, permitting awider range of applications of the arrangement.

Referring to FIG. 9, in operation a secure connection is establishedbetween the client controller 20 and the proxy controller 21 on port1073 in an identical manner to that described above with reference toFIG. 3. However, with in-bound connections through the outer firewall 7being barred, the proxy controller 21 must initiate a secure connectionwith the control station 11 rather than the control station 11 initiatethe connection with the proxy controller 21 as in the embodiments above.The proxy controller 21 may be triggered to establish the connection onport 1073 with the control station 11, through the outer firewall 7,either upon receipt of a connection request from the client controller20 or at some earlier time. The connection may be established using asimilar procedure to that described above to connect client controller20 to proxy 21.

Referring to FIG. 10, a process is shown for establishing a connectionbetween the proxy controller 21 and control station 11, being largelyidentical to that shown in FIG. 3 as between client and proxycontrollers 20, 21, and to that shown in FIG. 7 but with proxycontroller and control/monitor station roles transposed. On startup, forexample, when the proxy controller 21 is first booted up, or uponreceipt or completion of a connection request from the client controller20, the proxy controller 21 sends a TCP (Transport Control Protocol)connection request to the control station 11 on port 1073 (step s31). Onthe assumption that the control station 11 is already online, it acts asa server listening for incoming connection requests. When it receivesthe connection request, it returns a response to the proxy controller 21(step s32), which in turn sends an acknowledgment to the control station11 (step s33), resulting in the establishment of a TCP connectionbetween the two, in a way which is standard and well known.Subsequently, mutual authentication and encryption set-up is carried outbetween the proxy controller 21 and control station 11 (step s34) usingthe industry standard Secure Sockets Layer (SSL) protocol, or the latestversion known as the Transport Layer Security (TLS) protocol, in a waywhich is, once again, very well known. Once a properly authenticatedconnection between the proxy controller 21 and the control station 11 isestablished as a result of this procedure, the connection remains open,subject to equipment failure, scheduled maintenance and so on, ready forthe transfer of instructions from the control station 11. The proxycontroller 21 will continually try and re-establish the connection if itis lost. It may have to drop and re-establish the connection on ascheduled basis if the outer firewall 7 only allows continuousconnections to exist for a certain maximum time.

Having established secure connections between client and proxy 20, 21and between proxy and control station 21, 11, equipment control messagesmay be sent from the control station 11 to the client controller 20 viathe proxy controller 21, as in the earlier embodiments.

Where, for example, so called “legacy” equipment is to be controlled atthe remote site 3, the proxy controller 21 may be arranged to performcertain protocol conversions, providing a point of interface between thecontrol station 11 and the client controller 20. In that arrangement,the nature of the authentication step s34 in FIG. 10 may be different tothat at step s4 in FIG. 3, particularly where different protocols orencryption techniques are employed at each stage.

Embodiments of the invention have been described in the context ofconference equipment control and monitoring of remote events. However,it will be apparent to the skilled person that the invention isapplicable to a wide range of types of remote interaction withequipment, including further specific examples such as the control ofbroadcasting equipment and control and monitoring of security equipment.

1. A system for remotely controlling one or more devices over acommunications network, wherein the network includes first and secondnetwork sides and means for controlling access between the first andsecond sides, the system comprising: a first controller connected to thenetwork on the first network side for receiving device control messagesfrom a control station; and a second controller connected to the networkon the second network side, for receiving the device control messagesfrom the first controller and controlling the one or more devices inresponse thereto; wherein the first controller is configured to send thedevice control messages to the second controller after initiation of aconnection to the first controller by the second controller.
 2. A systemaccording to claim 1, wherein the second controller initiates theconnection by sending a connection request to the first controller.
 3. Asystem according to claim 1, wherein the access control means isconfigured to prevent connection requests from the first controller fromreaching the second controller.
 4. stem according to claim 1, whereinthe system is configured to maintain a connection between the first andsecond controllers following receipt of the connection request from thesecond controller at the first controller, to permit the firstcontroller to send the device control messages to the second controllerwhen said messages are received at the first controller.
 5. stemaccording to claim 4, wherein the device control messages are sent in anencrypted form.
 6. A system according to claim 1, wherein the first andsecond controllers are located at a site remote from the controlstation.
 7. stem according to claim 6, wherein the communications pathbetween the control station and the remote site comprises a wide areanetwork.
 8. A system according to claim 7, comprising further accesscontrol means between the wide area network and the first controller. 9.A system according to claim 1, wherein the or each access control meanscomprise a firewall.
 10. A system according to claim 8, wherein theaccess control means and the further access control means comprise innerand outer firewalls and the first controller is connected in ademilitarised zone between the inner and outer firewalls.
 11. A systemaccording to any one of the preceding claims, wherein the first andsecond controllers communicate over Transport Control Protocol (TCP)port
 1073. 12. A system according to claim 1, wherein the controlstation is configured to receive information relating to an eventoccurring at the one or more devices via the first and secondcontrollers.
 13. A system according to claim 12, wherein the controlstation generates a device control message in response to the receivedinformation.
 14. A system according to claim 12, wherein the controlstation initiates a connection to the first controller to enable it toreceive said information from the first controller.
 15. A systemaccording to claim 12, wherein the first controller initiates aconnection to the control station to enable the control station toreceive said information from the first controller.
 16. A systemaccording to claim 15, wherein the first controller is triggered toinitiate the connection to the control station after initiation of theconnection to the first controller by the second controller.
 17. Asystem according to claim 1, wherein the second controller includes oneor more device drivers for controlling said one or more devices.
 18. Amethod of remotely controlling one or more devices over a communicationsnetwork, wherein the network includes first and second network sides andmeans for controlling access between the first and second sides, themethod comprising: initiating a connection to a first controllerconnected to the network on the first network side from a secondcontroller connected to the network on the second network side; sendingdevice control messages from a control station to the first controllerand then from the first controller to the second controller.
 19. Asystem for remotely monitoring one or more devices over a communicationsnetwork, wherein the network includes first and second network sides andmeans for controlling access between the first and second sides, thesystem comprising: a monitor station connected to the network on thefirst network side for receiving information concerning said one or moredevices; a first controller connected to the network on the secondnetwork side for receiving said information and sending said informationto the monitor station; and a second controller for monitoring the oneor more devices and sending said information to the first controller;wherein the first controller is configured to send said information tothe monitor station after initiation of a connection to the firstcontroller by the monitor station.
 20. A system according to claim 19,wherein the system is configured to maintain a connection between themonitor station and the first controller following receipt of theconnection request from the monitor station at the first controller, topermit the first controller to send information received at the firstcontroller to the monitor station without requesting a new connection tothe monitor station.
 21. A system according to claim 19, wherein themonitor station generates device control messages in response to thereceived information.
 22. A system according to claim 21, wherein thedevice control messages are sent to the devices via the first and secondcontrollers.
 23. A system according to claim 19, wherein the secondcontroller is connected to the network on the second network side.
 24. Asystem according to claim 19, wherein the first controller is located ata site local to the monitor station and the second controller is locatedat a site remote from the monitor station.
 25. A system according toclaim 24, wherein the communications path between the monitor stationand the remote site comprises a wide area network.
 26. A systemaccording to claim 25, wherein the first controller is located in ademilitarised zone between a first firewall which separates the firstcontroller from the monitor station and a second firewall whichseparates the first controller from the wide area network.
 27. A systemaccording to claim 26, further comprising a third firewall separatingthe second controller from the wide area network.
 28. A system accordingto claim 27, wherein the third firewall is configured not to permitinbound connection requests to the second controller.
 29. A systemaccording to claim 19, wherein the monitor station and the firstcontroller communicate over Transport Control Protocol (TCP) port 1073.30. A method of remotely monitoring one or more devices over acommunications network, wherein the network includes first and secondnetwork sides and means for controlling access between the first andsecond sides, the method comprising: initiating a connection to a firstcontroller connected to the network on the second network side from amonitor station connected to the network on the first network side;sending event information relating to the one or more devices from thesecond controller to the first controller and then from the firstcontroller to the monitor station.
 31. A method according to claim 30,further comprising generating device control messages for controllingthe devices in response to the received event information.